The Transmission Control Protocol (TCP) is one of the most commonly used transport protocols in IP-based communication networks, such as the Internet. TCP provides reliability on top of the unreliable IP protocol, in-order delivery of data and a network congestion control mechanism to be outlined later. TCP is the primary end-to-end transport layer protocol in the Internet for non-real time data including data arising from e.g., web browsing, file-downloading and e-mail applications. The TCP layer is above the IP layer, the link layer and the physical layer, and below the application layer.
TCP uses a sliding window protocol to control a rate of sent data. A TCP sending node's window defines what the sending node can send, and is based on a TCP receiving node's advertised or offered window (rwnd) and a congestion window (cwnd) calculated by the sending node in the congestion control algorithm. The size of the TCP sending node's window is defined as the minimum of the receiver window (rwnd) and the congestion window (cwnd).
When the TCP sending node receives an acknowledgement (ACK) from the TCP receiving node, it can transmit as many new segments as were acknowledged. The new segments move towards the TCP receiving node and they are later acknowledged. The spacing of the ACKs determines the rate at which new packets are sent. This property is known as self-clocking, an example of which is shown in FIG. 1. In this example, a TCP sending node 1 sends packets to a TCP receiving node 2, which sends acknowledgements. Congestion is caused by a bigger ‘pipe’ 3 at the sending node feeding a smaller ‘pipe’ 4 on the downlink to the TCP receiving node 2. The rate at which the packets flow through the downlink pipe 4 is also the rate at which the ACKs are sent back to the TCP sending node 1.
A TCP header is used to carry information about parameters such as window size, packet sequence number, acknowledgement number and so on. There are also options to enhance performance, e.g. a time stamp option giving a Round Trip Time (RTT) estimate, maximum segment size (MSS) and Selective Acknowledgements (SACK). Indications about use of options are in most cases only transmitted during the initial SYN and SYN/ACK phase of a 3-way-handshake performed to establish the TCP connection. The TCP ACKs sent from the TCP receiving node to the TCP sending node 1 contain no data but the header itself (20 bytes), and possible options (max 40 bytes).
An end-point in the network cannot know the true pipe capacity (PC) for the TCP connection; instead it has to probe the PC and to find the bottleneck rate. TCP uses three types of input to determine congestion; An ACK indicates that more bandwidth is available, if a packet is dropped it is indicative of light congestion, and if many packets are dropped or time out, it is indicative of serious congestion. TCP acts on these signals by changing the send window or by starting over with the initial settings (the slow-start mechanism).
Congestion control in TCP uses four main algorithms: slow-start, congestion avoidance, fast-retransmit and fast-recovery algorithms. The slow-start algorithm and the congestion avoidance algorithm are independent algorithms with different objectives, although in practice they are implemented together. The congestion avoidance algorithm probes for more bandwidth in a linear fashion by increasing the congestion window by 1/cwnd every time an ACK is received. The slow-start algorithm also increases the congestion window (cwnd) by one segment every time an ACK is received. This opens the congestion window exponentially until congestion is experienced. In this phase the behavior is very dependent on the RTT, and therefore improvements in end-to-end RTT have a big effect on end user performance, especially for short TCP connections. Many servers on the Internet currently apply an initial window size of three TCP segments, but larger sizes are being discussed.
The TCP send rate is therefore increased until reaching the maximum available throughput. The maximum TCP throughput is related to the RTT and the TCP receive window (rwnd) size, as shown in Equation 1 below.
                              TCP          ⁢                                          ⁢          throughput                ≤                              TCP            ⁢                                                  ⁢            receive            ⁢                                                  ⁢            window                    RTT                                    Eq        .                                  ⁢        1            
Equation 1 shows that the maximum TCP throughput increases if the RTT is reduced. It also indicates that the maximum TCP throughput can be reached more quickly if the congestion window size reaches a maximum more quickly.
One quick way of accomplish this is to implement a TCP proxy 5 somewhere in between the TCP sending node 1 and the TCP receiving node 2, as illustrated in FIG. 2. The TCP sending node 1 in this example is a TCP server located in the Internet 6, and the TCP receiving node 2 is a mobile device such as a User Equipment (UE) attached to a mobile network 7. The TCP connection is split into two legs; TCP1 is established between the TCP sending node 1 and the TCP proxy 5, and terminates at the TCP proxy 5. Acknowledgements are transmitted back to the TCP sending node 1 from the TCP proxy 5. From the TCP proxy 5, another TCP connection, TCP2, is set up towards the TCP receiving node 2. Each TCP connection, TCP1 and TCP2, has its own flow control loop. This architecture is termed Split TCP, and reduces the RTT. The TCP proxy 5 may be located at one of several interfaces within or outside the mobile network. For example, in a Long Term Evolution (LTE) network, the TCP proxy 5 may be located at the SGi interface between a TCP Server and a Public Data Network Gateway (PGW).
It is possible to speed up TCP transmission by applying specific parameter settings or algorithms at the TCP server (where the server is the TCP sending node) side of the connection. This may also be achieved at the TCP proxy 5.
In the situation with or without a proxy, but where TCP packets are sent over a mobile network 7, a congestion avoidance mechanism may be initiated owing to congestion in the mobile network. It is difficult to make an informed decision as to how much to decrease the send window size in this case, as the loss of a packet may be caused by factors other than congestion, such as an isolated dropped packet in the RAN. For some services or use cases, such as sending audio or video data, the congestion avoidance mechanism can give a large negative impact. If the transmission rate backs off too much, or reverts to the initial window size, this can have a serious effect on the end-user's quality of experience (QoE). Furthermore, unnecessary backing off using the congestion avoidance mechanism can lead to underutilization of resources in the mobile network 7. Furthermore, some types of service (setting up short-duration TCP connections that do not always enter the TCP fast recovery phase, such as email or web browsing) are less affected by a congestion avoidance mechanism than streaming services such as audio or video (setting up longer-duration TCP connections, having specific requirements on latency and bit rate).